​

Dezy It - Growth Sprints made easy

Built for Product Teams to scale their product-led growth by rapid experimentation and validation

​

​

Ideal Customer Profile (ICP)

​

​

​​Understanding the User & JTBD

Structured Approach for User Interviews:

• Talk about their process/experience
• Problems, insufficiencies
• Identify if they are ideal ICP - Show them quick demo and share the link post call. 
• Then follow-up for next call

​

User Insights:

Tushar Gupta - Product Growth Manager Times Internet

​Process:

• Define the metrics/goals like getting more people to buy
• Top to bottom approach - First try to get the north star metrics and then plan on talking to users about problem
• Talking to user is a challenge, have to give incentive
• Then the designers design the flow and discuss with the tech team
• Bandwidth issue is huge in my company, have limited design resource and technical resource for experiments
• Use data analysis for measuring the success of the experiment
• And then set up weekly call with stakeholder to show progress

Tools used:

• Google docs
• Jira
• Notion - sometimes

Challenges:

• Awareness is the main issue, the team is not aware of product-led growth. They understand growth experiments as marketing activities. I have to convince a lot to people on why we are doing this.

Feedback on Product

• Sounds interesting
• Can I try the product? What is the pricing?

​

Gunjan Maheshwari - Senior Product Manager, Global Ecomm. Dell

Process:

• There are many product teams and they have product managers.
• Growth product team is very different from these
• We as the growth team look at data and suggest changes that directly impact revenue.
• We target low hanging product revenue changes and optimizations
• Growth team suggest and align the product teams
• Looking at data validates the experiments success.
• A/B Testing for design changes.
• Design team are involved and growth product team is closely connected with Design team to quickly mockup things.
• The process is documented in PPT
• There is a 2 week period to define and prepare PPT. Then there is alignment calls to showcase PPT.
• If anyone have any concerns, they comment on PPT. Then after discussion we come to middle ground and assign to product line manager.
• There is research team who speaks to users. They have their own methods on capturing data and we get insights from them.
• The product insight we get after we launch the product through A/B testing.
• The Stakeholder look at topline. yes or no

Tools used:

• Used PPT
• share ppt for finalize on the designs and changes

Challenges:

• Alignment issues. Sometime you as a growth team you want to get the revenue boost. The product team denies sometimes so they can take those ideas within their backlog and highlight their team.
• To convince product teams sometimes it’s data or they do it when high order influence it there that this is coming from Growth product team.
• There are a lot of alignment calls

Feedback on Product

• Design looks good and side panel seems interesting.
• It’s possible to buy. As there are alignment issues. if one team has to do it, it’s easier for dezy it to enter but convincing all the teams might be challenging.
• If they all the using Jira and also the growth product team is not liked by people so

​

Shubham Baranwal - Product Manager, Ninjacart

Process:

• Define the metrics
• Then it going to drill down by how product team to contribute
• Consistency increase the percentage of users
• You have to give the percent results
• Defining user 0-1 and existing users(Churned)
• Define their journey/user flow
• Supporting Levers to increase the metrics from pain points
• While defining ideas/experiments - Need to define benchmarking the numbers/metrics
• Designers are included on experiments. sometimes not required for tech experiments
• Validation Happens
• Stake holders are required in major changes
• Tools I use are Figma and whimsical, for documentation I use Jira.

Challenges:

• User insights is a challenge as I run the experiment on huge user base, so I don’t find out whether the experiment is wrong or the user base is wrong.
• I do target experiments based on user behaviours.

Feedback on Dezy It

• It is good repository of items
• This is good structure. If growth experiment is happening at a rapid pace. When you are moving fast you can miss few steps. This structure helps.
• Can you customize these steps?
• Once they adapt dezy it, no one has to worry about where to find the relevant documents and items for growth sprints.
• It’s a one stop shop for reference as sometimes you forgot why you have done this change.
• The experiments that you are running are working on not? How can I align my teammate.
• This is ideal for companies where experiments happening rapidly.
• The Buyer is CPO and they get influenced by Product and the person who will pay is CFO. They will analyze ROI of the tool.

​

Niyatee Dwivedi - Product Manager, Bharatpe

Process

• Construct of the feature should be well defined
• I don’t include tech because they go deep into feature level
• My objective and their objective will never align
• I go to them to analyze impact from tech on live product - I go to them with ideas and ask impact
• Collaboration on Product manager level - takes a lot of time
• I do not include growth people in ideation time. I include them on Impact analysis time - Cause Benefit analysis
• Prefer A/B testing
• As a product manager, the requirement either comes from my end. I derive the requirement or it comes from CXO's. I set up priorities
• I prepare very high level wireframe to represent ideas
• I don’t include designers at planning state as it is a time consuming state. When we are close to starting development that’s when I include designers.
• I take a call on which ideas to go ahead with and share with Design and Dev
• We speak to user where basic features are ready
• Validation at design level happens on the companies which are retail focused. Mainly B2C.

High Level summary

• Growth is not just about numbers but also about the product's essence.
• Aligning objectives between growth scenarios and tech processes can be challenging due to differing perspectives.
• Aim to ship out the best-fit product feasible within constraints, targeting 70% stakeholder satisfaction.
• Testing results should be presented in a clear format, indicating priorities for implementation.
• Evaluating concepts and impact analysis on requirements to avoid unnecessary tasks.
• Understanding the tech team's response rate regarding feasibility and agreement on requirements.
• Limited involvement of designers due to resource scarcity; focus on practicality over elaborate designs.
• Coordination with designers at key stages to align logical flow with technical implementation.
• Figma and Miro are primarily used for idea framing.
• A/B testing is crucial for campaigns to gauge user responses effectively.
• Engaging users after developing an MVP helps in refining the product based on initial feedback.
• Features are validated after spending 15-20 days in development through user interactions.

Apoorva Saraswat - Ex Product Manager Lenskart

Process, Problems & Insufficiencies -

• Start with a discussion, decide the experiments, measure the impacts and efforts as much as possible.
• Check the availability of the engineering team, not a lot of bandwidth so had to be plan and prioritise.
• Main Target was revenue, so we used to prioritise according to that.
• For Sprints, we were maintaining Jira on Fridays but not dilligently, would end up using Google Docs.
• The process was quite ad hoc, we had a freelance designers who I was the main touch point for. We had documentation but no process or format.
• The team for this would be me, another PM and a business person.

​

Post Demo Feedback -

• At first glance, it seems very easy to use even though I have not seen something like this.
• Liked the exerimental approach and the fact that there was context and transparency in the approach.
• Showed interest to try with a proper use-case in her next role.

JTBD

Primary - Functional

Growth Sprints, baby! ​

• Contextual Documentation​
• Stakeholder Alignment​

• Effective Collaboration, Experimentation & Validation ​

​

Secondary - Financial

• Great Experiences = Happy Customers = More Revenue
• Increased Retention - Lifetime Value of customers
• Effecient Experimentation - Saves Time & Money
• Product-led Growth System - Increased Profitability

​

​

​

Onboarding Teardown

​

We are currently exploring 2 kinds of approaches when it comes to onboarding.

What we are doing?

Online - Self Onboarding

A user finds us online or gets reached out to by a representative and come on to our Website/Sign Up page

​

​

How am I feeling while being onboarded onto this product?

Lot of steps, a long process. I do resonate with the value proposition at first but I get exhausted before I am able to reach the first "aha" moment. Forget about getting activated. The UI is clean and seems intuitive but the process feels stretched and overwhelming to do on my own.

​

​

What part of the On-boarding experience is giving me the "aha" moment?

First "aha" moment is before signing up, when you notice relatable problems and a possible solution. Post Sign up, the product lacks "aha" moments. Once the user completes the first sprint is when the reach an "aha" moment, which is not happening as of now. It takes 4-6 days to finish the first sprint which is not happening as of now.

​

​

Hypothesis:

• 80% of users, falling through the onboarding process because of the complexity before reaching any 'Aha" moment and getting activated.
• 7/10 Product Managers, would be new to the concept and would have a learning curve.
• Exploring a Demo Led Approach with a human touch and a structured, guided onboarding for product teams.

​

​

Activation Metrics

Hypothesis:

Linking it to the primary JTBD - Functional

Growth Sprints, baby! - First Sprint Completed in 7 days with at least 3 team members

• Contextual Documentation - First time a product manage completes the sprint, they have thorugh and contextual documentation which can be shared with designers, engineers etc. For them to know the "Why?" behind what they are expected to do.
• Stakeholder Alignment - First Sprint presented/shared with the Stakeholders. Stakeholders easily able to understand the context and comment on the file/process staying looped in via notifications and email reports.

• Effective Collaboration, Experimentation & Validation - First Sprint Completed successfully within 7 days with at least 3 members added to the workspace, Second Sprint intiatied in 30 days. The product team realises the value and start implementing it as a proactive process tool.

D1, D7, D30 Retention

D1 - User Signs Up - Initiates a Sprint

D7 - User Completes first sprint and adds at least 3 members. Recieves first report

D30 - User has shared first sprint, started executing experiments looped in at least 5 members and has started the second Sprint.

DAU/MAU

DAU - User Logs in, takes action (View, Comment, Edit, Share etc.)

MAU - New Sprint Created & Completed on the Workspace

​